Appearance
03. 架构模式与技术选型
版本：
v1.2最后更新：
2026-07-09
1. 为什么要学架构模式
很多人学 Agent 时，一上来就看“多 Agent”“超级助手”“自动化研究系统”，但没有先理解模式差异，最后很容易把所有问题都做成复杂系统。
学架构模式的目的，是回答两个问题：
- 这个业务适合哪种组织方式？
- 我为什么选这个，而不是更简单的方案？
2. 最常见的 6 种模式
2.1 单 Agent + Tools
结构：
- 一个 Agent
- 一组工具
- 一个控制循环
适合：
- 搜索总结
- FAQ 增强问答
- 基础文档助手
- 数据查询助手
优点：
- 简单
- 易调试
- 便于评测
缺点：
- 任务复杂时容易变大 Prompt
2.2 Router 模式
结构：
- 一个入口分类器
- 多条处理链路
适合：
- 问题类型差异明显
- 每类问题都已有相对稳定处理逻辑
例子：
- 售前走知识库链路
- 售后走工单链路
- 技术问题走文档 + 代码链路
优点：
- 稳定
- 容易控风险
缺点：
- 路由策略不好时会误分流
2.3 Planner-Executor
结构：
- Planner 负责拆解
- Executor 负责执行
适合：
- 复杂任务
- 明显多步骤问题
- 子任务之间有依赖
优点：
- 适合复杂目标
缺点：
- 计划质量差时会拖累全局
2.4 Reviewer / Critic
结构：
- 一个生成者
- 一个审查者
适合：
- 输出质量敏感
- 高风险文本生成
- 需要错误发现与修正
优点：
- 有助于提高结果质量
缺点：
- 成本和延迟会上升
2.5 Multi-Agent
结构：
- 多个 specialist
- 管理者或 handoff 机制
适合：
- 角色和能力差异非常明显
- 不同模块需要不同工具、权限或模型
根据 OpenAI 官方 orchestration and handoffs 指南在 2026-07-01 的可访问内容：
- 一个 specialist 需要不同工具面、不同审批策略或不同输出风格时，拆分 Agent 才更有意义
优点：
- 能清晰隔离职责
缺点：
- 非常容易过度设计
2.6 Graph / Stateful Workflow
结构：
- 显式节点
- 显式边
- 共享状态
- 持久化
适合：
- 长任务
- 状态复杂
- 需要恢复
- 需要人工节点
- 需要可靠重试
根据 LangGraph 官方文档在 2026-07-01 的说明：
- LangGraph 是一个偏底层、偏编排的框架，重点在
long-running, stateful agents
2.7 Manager 作为编排器，specialists 作为工具
除了 handoff，还有一种很常见、也更容易控住复杂度的模式：
- 顶层 manager 负责路由、阶段推进和停止条件
- specialists 被当成
tools-as-agents或受控子能力调用
它和 Multi-Agent 的差别很关键：
- handoff 更像控制权迁移
- manager + specialists 更像统一控制下的受控分工
这类模式更适合：
- 你确实需要多个 specialist 的推理能力
- 但不希望对话控制权频繁漂移
- 你还想保留统一审批、统一 trace 和统一终止条件
如果系统最核心的问题是“多能力协作，但还不想进入真正的多控制权世界”，这类模式通常比 full handoff 更稳。
3. 如何选模式
可以按下面顺序判断：
第一步：任务路径是否稳定
- 稳定：优先工作流
- 不稳定：考虑 Agent
第二步：是否需要动态工具选择
- 不需要：固定工作流即可
- 需要：单 Agent 起步
第三步：是否存在明显角色分工
- 没有：不要急着多 Agent
- 有：再考虑 Router 或 Multi-Agent
第四步：是否需要长状态和恢复
- 不需要：普通循环就够
- 需要：考虑图式工作流或持久化框架
第五步：失败以后，谁来解释和兜底
这一问经常被漏掉，但它特别重要。
- 如果失败后只需要重试或改写 prompt，单 Agent 往往够用
- 如果失败后要解释是哪条链路、哪个工具、哪个审批点出了问题，Router / Graph / manager 模式会更合适
- 如果失败后责任边界要分到不同 team / specialist，才更值得拆真正的 Multi-Agent
很多系统模式选型做偏，根源不是技术，而是：
- 事前没有想清楚失败归因和责任归因
4. 一个很实用的选型表
| 场景 | 推荐模式 | 不推荐一开始就上 |
|---|---|---|
| 搜索总结 | 单 Agent + Tools | Multi-Agent |
| 企业 FAQ | RAG + Router | Planner-heavy Multi-Agent |
| 工单处理 | Router + Workflow + 审批 | 无约束自主 Agent |
| 研究助手 | 单 Agent / Planner-Executor | 复杂 Graph 先行 |
| 长任务编排 | Stateful Workflow | 纯 Prompt 驱动 |
| 高风险业务操作 | 工作流 + 审批 + 局部 Agent | 直接全自动执行 |
4.1 再加一张“六维选型卡”，会更接近真实生产
很多系统选型失败，不是因为不知道这些模式叫什么，而是因为少看了几条真正影响架构的维度。
更实用的判断通常至少要一起看这 6 维：
| 维度 | 低时更像什么 | 高时更像什么 |
|---|---|---|
| 路径不确定性 | 固定工作流 / Router | Planner、Agent loop、Graph |
| 工具异质性 | 单 Agent + 少量工具 | manager + specialists / Multi-Agent |
| 副作用风险 | 读操作 Agent | 审批流、Graph、action specialist |
| 状态持续时间 | 单轮 / 短 run | Stateful workflow、checkpoint、resume |
| 责任边界 | 单 team / 单 owner | Router、handoff、specialist 分责 |
| 执行环境复杂度 | 普通 API / 检索 | workspace、shell、浏览器、异步作业 |
这张表想提醒的一件事是：
模式选型不只是看“任务复杂不复杂”
还要看：
- 状态会不会拖很久
- 工具是不是已经分成不同权限面
- 失败后是不是要按 team / specialist 归因
- 有没有执行工作区这种另一层复杂度
5. OpenAI、LangGraph、MCP 各怎么学
5.1 OpenAI 路线
优先学什么：
- Responses API
- Tools / function calling
- Agents SDK
- Orchestration
- Guardrails
- Evals
适合：
- 从零搭一个实用 Agent
- 学官方范式
- 学工具调用和 specialists
这一条路线特别适合先建立一个判断：
官方 SDK / API解决的是 agent control plane
也就是：
- agent definition
- tool use
- state / results
- orchestration
- approvals
- observability
如果你现在主要卡在：
- specialist 怎么定义
- handoff 怎么做
- tool call 怎么稳定
- 审批怎么插进 loop
那 OpenAI 路线通常最贴题。
5.2 LangGraph 路线
优先学什么：
- Overview
- Workflows vs agents
- Graph API
- Persistence
- Thinking in LangGraph
- Human-in-the-loop
适合：
- 状态很重要
- 任务很长
- 想显式控制节点和分支
LangGraph 路线最适合补的，不是“怎么多建几个节点”，而是：
- checkpoint 放在哪里
- interrupt 后从哪里 resume
- 哪些边允许补偿、重试和人审
- graph state 如何和应用状态一起治理
5.3 MCP 路线
优先学什么：
- MCP 的定位
- 工具与资源的组织
- MCP server 的设计
- 如何把内部系统能力封装出来
适合：
- 企业内部系统接入
- 多数据源接入
- 可复用能力平台化
但要先记住一条边界：
MCP更像工具与上下文接入协议- 不是架构模式本身
它解决的是：
- tool / resource 如何暴露
- schema 如何统一
- 外部系统如何标准化接入
它不直接替你决定：
- 是单 Agent、Router、Graph 还是 Multi-Agent
- 谁来审批
- 谁来做状态恢复
- 谁来承担执行环境
5.4 还有一条经常被漏掉的路线：execution workspace
很多团队学完 OpenAI / LangGraph / MCP 后，还是会遇到一个现实问题：
- 真正卡住系统的，不是 agent pattern，而是 execution layer
例如：
- 需要读写文件
- 需要跑脚本
- 需要 shell / browser / sandbox
- 需要异步后台作业和可恢复工作区
这时更值得问的往往是：
- 应不应该先升级执行工作区，而不是先拆更多 agent
因为很多复杂度其实来自：
- 工具和环境的可执行性
而不是：
- 推理角色还不够多
6. 什么时候拆成多个 Agent
不要因为“多 Agent 很高级”就拆。
适合拆分的典型信号：
- 某个子任务需要完全不同的工具集合
- 某个子任务需要不同的审批策略
- 某个子任务需要不同模型
- 某个子任务输出风格完全不同
- 你希望 traces 里清楚看到职责分离
不适合拆分的信号：
- 只是 Prompt 太长
- 只是想“让它更像团队协作”
- 没有真实权限隔离需求
7. 什么时候“先单 Agent，再逐步升级”更合理
根据 OpenAI 官方 Building agents 学习路线与 Orchestration and handoffs 指南在 2026-07-07 可访问的说明，一个非常明确的经验是：
- 先从一个聚焦、指令清晰、工具边界明确的 agent 起步
- 只有在复杂度真实出现后，再拆 specialists 或 handoffs
这条建议背后不是保守，而是因为多 Agent 会同时放大：
- prompt 维护成本
- trace 阅读复杂度
- 工具暴露面
- 权限和审批设计
- 故障排查难度
所以更稳妥的升级路径通常是：
- 单次调用
- 单 Agent + Tools
- Router 或 Planner-Executor
- Graph / Stateful Workflow
- 只有在角色确实分化时再上 Multi-Agent
如果系统一开始就跳到第 5 步，后面很容易进入“看上去很高级，实际上很难运营”的状态。
8. 什么时候优先图式工作流
满足下面几个条件时，图式工作流通常比“自由循环 Agent”更合适：
- 步骤之间依赖强
- 状态字段多
- 需要恢复与重试
- 需要多个人工节点
- 需要可审计的执行路径
这类系统本质上更像：
- 有模型参与的流程引擎
而不是：
- 完全自主的数字员工
9. 选型时不要只看“任务复杂度”，还要看四个维度
很多人选模式时，只会问一句：
- 这个任务复不复杂
但真实系统里，更值得看的其实是四个维度：
| 维度 | 低时更像 | 高时更像 |
|---|---|---|
| 路径不确定性 | 固定 workflow | Agent / Planner |
| 副作用风险 | 读多写少 | workflow + approval |
| 状态生命周期 | 短会话 | graph / stateful runtime |
| 角色分化程度 | 单 Agent | router / multi-agent |
这样判断会比“听起来复杂就上多 Agent”稳很多。
例如：
- 问答类研究助手：路径不确定性高，但副作用低，常从单 Agent 起步
- 工单处理：副作用和审计要求高，更适合 Router + workflow + approval
- 长任务编排：状态生命周期长，优先 graph
9.1 再加两个维度，选型会更接近真实生产
上面四个维度已经很实用，但企业里通常还值得再补两个：
| 维度 | 低时更像 | 高时更像 |
|---|---|---|
| 权限 / ownership 差异 | 单 Agent / manager | Router / Multi-Agent / 明确 specialist |
| 恢复与审计要求 | 普通循环 | Graph / stateful runtime / 审批流 |
把这六个维度一起看，会比只看“复杂不复杂”靠谱很多。
例如：
- 两个子任务都不复杂，但权限完全不同：更可能要拆 specialist
- 任务本身不长，但审批和事故审计要求极高：更可能要走 workflow + approval
- 路径不确定性很高，但所有动作都是只读：单 Agent + tools 可能已经足够
9.2 再往下拆，其实是在选三层控制面
很多选型讨论表面上在比：
- 单 Agent 还是 Multi-Agent
- Graph 还是 Planner
但真正决定架构的，往往是这三层有没有分开：
orchestration planeapproval / guardrail planeexecution plane
更直白地说：
- orchestration 决定谁负责当前阶段、状态怎么继续
- approval 决定哪些动作被阻断、审查、放行
- execution 决定任务到底运行在什么环境里
如果这三层没拆开，就很容易出现这些假问题：
- 其实是审批问题，却被误以为要拆更多 agent
- 其实是执行环境问题，却被误以为要上 graph
- 其实是状态恢复问题，却被误以为 prompt 不够强
所以模式选型更成熟的问法通常是：
- 当前复杂度到底主要长在哪一层控制面
10. Router、Planner 和 Multi-Agent 不是同一件事
这三类模式经常被混着说，但它们解决的问题并不一样。
Router
核心问题是：
- 先判断“请求应该走哪条链路”
它更像入口分发器。
Planner-Executor
核心问题是：
- 一个复杂目标如何拆解成可执行步骤
它更像任务分解器。
Multi-Agent
核心问题是：
- 不同角色是否真的需要不同工具面、不同权限、不同模型和不同治理策略
它更像职责隔离体系。
如果把三者混在一起，常见后果就是：
- 本来只需要路由，却做成多 Agent
- 本来只需要计划拆解，却引入一堆 handoff
- 本来只需要一个 Agent 调几个工具，却搞出假团队协作
10.1 Router 最怕的是“错误分流后无纠偏”
Router 并不只是一个分类器，它还应该考虑：
- 路由置信度不足怎么办
- 路由错了以后能否退回主链
- 某条链路失败时是否允许 fallback 到别的链路
如果没有这些设计，Router 很容易变成：
- 入口处一次分错
- 后面整条链路都在错误前提上继续
更稳的做法通常会补：
- default safe path
- low-confidence fallback
- human escalation
- trace 中的 route decision evidence
10.2 Planner 最怕的是“计划看起来完整，但执行面接不住”
Planner-Executor 的最大风险通常不是“不会拆解”，而是：
- 拆解结果和实际工具面不匹配
- 计划没有显式中止条件
- 子任务之间依赖关系不清楚
所以真正成熟的 Planner 设计通常至少还要配：
- action schema
- step budget
- stop / abort rule
- replan trigger
如果没有这些约束，Planner 很容易从“复杂任务拆解器”滑向“高成本回环制造机”。
10.3 Reviewer / Critic 不一定要成为独立 agent
很多团队一想到“要复核”，就立刻把 reviewer 做成独立 specialist。
但更实用的判断通常是先看：
- 它是一次本地校验
- 一个固定 review node
- 还是一个真的需要独立工具面和审批边界的 reviewer
如果 reviewer 只是：
- 检查格式
- 检查引用
- 检查风险标签
那很多时候：
- 一个 guardrail
- 一个 structured review step
- 一个 graph 节点
就足够了。
只有在 reviewer 需要：
- 独立工具集合
- 独立模型档位
- 独立审批或签字责任
时，它才更像真正值得拆开的 agent。
11. Graph 价值不只是“节点多”，而是状态可治理
不少人把 Graph 理解成：
- 很多节点连接在一起
这太表面了。真正让图式工作流有价值的，不是图长得像流程图，而是它更容易显式管理这些对象：
- 状态字段
- 分支条件
- 恢复点
- 人工节点
- 重试和补偿
根据 LangGraph 官方 Thinking in LangGraph 与 Persistence 文档在 2026-07-07 可访问的说明，图式工作流特别适合长运行、状态驱动、需要中断恢复和 human-in-the-loop 的系统。
所以：
- 如果你主要问题是“模型该不该继续探索”，单 Agent 可能够用
- 如果你主要问题是“状态如何跨节点稳定推进”，graph 往往更合适
11.1 graph 真正多出来的是 checkpoint、resume 和人工节点
很多团队对 graph 的第一印象是“图更复杂”，但对生产系统来说，它真正多出来的价值通常是：
- checkpoint 能落在哪里
- 中断后从哪里 resume
- 哪些节点允许人工介入
- 哪些边允许补偿、重试或回滚
这也是为什么：
- 长任务
- 审批流
- 人工 review
- 多阶段发布
这些系统一旦变认真，最后都更容易走向显式 graph，而不是只靠自由 prompt 循环。
12. 多 Agent 真正成立，往往依赖权限和工具边界
很多系统把多 Agent 做得很虚，角色名字很多，但本质差异不大。
真正值得拆分的多 Agent，通常具备下面至少两条：
- 工具集合明显不同。
- 审批策略明显不同。
- 模型能力或成本档位明显不同。
- 输出对象和责任边界明显不同。
- trace 中需要独立归因。
例如：
- 一个 research agent 只读搜索和检索
- 一个 action agent 才能发工单或改状态
- 一个 reviewer agent 只做质量把关和风险复核
这种拆法的价值在于：
- 限制每个 agent 的工具面
- 限制风险扩散
- 让评测和日志更容易归因
12.1 如果模型、工具、审批都没分化，就先别急着拆 agent
一个很实用的判断法是看三件事有没有一起分化：
- 模型档位是否不同
- 工具面是否不同
- 审批 / guardrail 是否不同
如果这三件事都没有明显变化，那很多“specialist”其实只是：
- prompt 模板略有不同
- 但控制面根本没分出来
这时更好的做法往往是：
- 继续保留单 Agent
- 在内部用 route / prompt profile / tool subset 做轻分层
而不是立刻做成多 Agent 拓扑。
13. 什么时候不要把“Prompt 太长”当作拆 Agent 的理由
Prompt 太长是个真实问题，但它通常先意味着：
- 上下文治理不够好
- 工具面暴露太宽
- 指令层和状态层没有分离
而不是立刻意味着：
- 你需要更多 agent
更好的排查顺序一般是：
- 先做上下文压缩和分层。
- 先缩小工具面。
- 先把稳定约束抽成系统模板。
- 再判断是否真的存在职责分工。
如果这几步都没做，就直接拆多 Agent，最后很容易得到：
- 多个同样冗长的 prompt
- 更多 handoff 成本
- 更难读的 traces
14. 选型时最常见的误区
误区 1：把复杂度当能力
复杂不等于强，尤其在 Agent 里更是这样。
误区 2：只从框架出发，不从业务出发
正确顺序应该是：
- 业务目标
- 风险边界
- 可观测性要求
- 再选框架
误区 3：忽略成本和延迟
多角色、多轮次、多工具调用，会迅速推高成本和响应时间。
误区 4：把“工具很多”误以为“必须多 Agent”
工具多并不自动等于要拆多个 specialist。
更该先问的是：
- 这些工具是否真的属于不同权限面
- 是否真的需要不同 owner 管理
- 是否真的需要不同审批策略
- 是否真的需要不同模型和输出契约
如果只是：
- 同一个 agent 需要访问多个读工具
那很多时候：
- 做好 tool subset
- 做好 tool description
- 做好 route / policy
就已经够了。
误区 5：把“架构模式”和“技术产品”混为一层
例如：
MCP不是 Multi-AgentLangGraph不是只能做 graph-heavy 系统Agents SDK不是一定只适合多 specialist
真正该先确定的是：
- 业务需要什么控制模式
然后再看：
- 用哪个框架 / 协议 / 执行层去承接
15. 一个足够实用的模式升级路线
如果你不想一开始就陷入过度设计，可以按这个顺序演进：
- 先做单 Agent + Tools，验证任务价值。
- 如果请求分布明显分层，再加 Router。
- 如果单任务内部步骤复杂，再加 Planner。
- 如果状态跨多节点长期存在，再落 Graph。
- 如果职责、权限、模型都明显分化，再拆 Multi-Agent。
这个顺序的好处是，每一步都在回应真实复杂度，而不是追逐抽象上的“更先进”。
15.1 还有一条常被忽视的支线：执行工作区升级路线
OpenAI 当前 Running agents、Sandbox agents、Shell 一类文档放在一起看，会发现一个很现实的问题：
- 有些复杂度并不是来自“要不要多 Agent”
- 而是来自“需不需要独立执行工作区”
例如：
- 需要目录和文件产物
- 需要脚本和命令执行
- 需要端口暴露和可恢复 workspace
这类场景更像：
- 单 Agent + tools
- 单 Agent + workspace / shell
- 再往上才是 graph 或 multi-agent
换句话说，很多系统真正先要升级的不是 agent 数量，而是 execution layer。
15.2 选型时最好把“发布边界”也一起定义
模式选型不只是开发时舒服不舒服，还会直接影响：
- 评测门禁怎么设
- 事故回滚怎么做
- trace 怎么归因
- 哪类变更需要灰度
举例：
- 单 Agent + tools：更适合做 prompt / tool schema 级灰度
- Router：更适合按 query bucket 看路由准确率和 fallback 命中
- Graph：更适合按节点看成功率、重试率、审批耗时
- Multi-Agent：更适合按 specialist 看工具误用率、handoff 成本和责任边界
如果发布边界想不清楚，架构通常也还没真的想清楚。
15.3 一个更像真实生产的升级顺序
很多团队的真实升级顺序并不是：
- 单 Agent -> Multi-Agent
而更像：
- 单次调用 + tools
- 单 Agent + controlled loop
- 单 Agent + workspace / shell / browser
- Router 或 graph，把状态和审批显式化
- manager + specialists
- 真正的 handoff / Multi-Agent
这条路线更贴近现实，因为很多复杂度最先长出来的地方通常不是：
- “需要更多脑子”
而是：
- 需要更清楚的状态
- 需要更重的执行环境
- 需要更明确的审批和恢复
16. 重点官方资源
以下资源已按 2026-07-09 复核到当前正式入口；其中部分 OpenAI 页面对脚本访问会返回 403，但浏览器入口仍可正常打开：
- OpenAI Building agents 学习路线：https://developers.openai.com/tracks/building-agents
- OpenAI Agents SDK：https://developers.openai.com/api/docs/guides/agents
- OpenAI Orchestration and handoffs：https://developers.openai.com/api/docs/guides/agents/orchestration
- OpenAI Running agents：https://developers.openai.com/api/docs/guides/agents/running-agents
- OpenAI Guardrails and human review：https://developers.openai.com/api/docs/guides/agents/guardrails-approvals
- OpenAI Sandbox agents：https://developers.openai.com/api/docs/guides/agents/sandbox-agents
- OpenAI Using tools：https://developers.openai.com/api/docs/guides/tools
- OpenAI Integrations and observability：https://developers.openai.com/api/docs/guides/agents/integrations-observability
- LangGraph Workflows and agents：https://docs.langchain.com/oss/javascript/langgraph/workflows-agents
- LangGraph Thinking in LangGraph：https://docs.langchain.com/oss/python/langgraph/thinking-in-langgraph
- LangGraph Persistence：https://docs.langchain.com/oss/python/langgraph/persistence
- LangGraph Interrupts：https://docs.langchain.com/oss/python/langgraph/interrupts
- MCP architecture overview：https://modelcontextprotocol.io/docs/learn/architecture
- Anthropic Building Effective Agents：https://www.anthropic.com/engineering/building-effective-agents
17. 本章后的实践建议
做任何 Agent 项目前，先写出这 5 行：
- 目标是什么？
- 为什么不是普通工作流？
- 为什么不是单次调用？
- 需要哪些工具？
- 哪些步骤必须人工确认？
只要能把这 5 行写清楚，你的架构选型就已经赢一半了。